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Abstract 

Previous  work  in  real-time  database  management 
systems  (RT-DBMS)  has  primarily  focused  on  sim¬ 
ulation.  This  paper  discusses  how  current  real-time 
technology  has  been  applied  to  architect  an  actual  RT- 
DBMS  on  a  real-time  microkernel  operating  system. 
A  real  RT-DBMS  must  confront  many  practical  is¬ 
sues  which  simulations  typically  ignore:  race  condi¬ 
tions,  concurrency,  and  asynchrony.  The  challenge  of 
constructing  a  RT-DBMS  can  be  divided  into  three  ba¬ 
sic  problems:  dealing  with  resource  contention,  deal¬ 
ing  with  data  contention,  and  enforcing  timing  con¬ 
straints.  In  this  paper,  we  discuss  approaches  to  each 
problem. 

1  Introduction 

As  real-time  applications  increase  in  complexity, 
so  do  their  data  requirements.  For  several  years,  re¬ 
searchers  have  sought  a  general  solution  to  the  prob¬ 
lem  of  collecting,  storing,  and  retrieving  data  in  real 
time  by  devising  database  management  systems  to 
manage  data  in  a  time-cognizant  and  predictable  man¬ 
ner  [7].  Despite  all  of  its  features,  a  conventional 
DBMS  is  not  quite  capable  of  meeting  the  demands 
of  a  real-time  system.  Typically,  its  goals  are  to 
maximize  transaction  throughput,  minimize  response 
time,  and  provide  some  degree  of  fairness.  A  real¬ 
time  DBMS  system,  however,  must  adopt  goals  which 
are  consistent  with  any  real-time  system:  providing 
the  best  service  to  the  most  critical  transactions  and 
ensuring  some  degree  of  predictability  in  transaction 
processing. 

StarBase  is  a  firm  real-time  DBMS  which  supports 
the  concurrent  execution  of  transactions  and  seeks 
to  minimize  the  number  of  high-priority  transactions 
that  miss  their  deadlines.  StarBase  uses  no  a  pri¬ 


ori  information  about  the  transaction  workload  and 
discards  tardy  transactions  at  their  deadline  points. 
StarBase  runs  on  top  of  RT-Mach,  a  real-time  oper¬ 
ating  system  under  development  at  Carnegie  Mellon 
University  [10]. 

StarBase  differs  from  previous  RT-DBMS  work  [1, 
2,  3]  in  that  a)  it  relies  on  a  real-time  operating  system 
which  provides  priority-based  scheduling  and  time- 
based  synchronization,  and  b)  it  deals  explicitly  with 
data  contention  and  deadline  handling  in  addition  to 
transaction  scheduling,  the  traditional  focus  of  sim¬ 
ulation  studies.  The  design  of  StarBase  appears  in 
Figure  1. 

The  StarBase  DBMS  receives  transaction  requests 
from  database  clients  and  places  them  on  a  priority 
queue.  It  is  assumed  that  database  clients  are  physi¬ 
cally  disparate  from  the  server,  so  they  pass  messages 
to  communicate  with  the  DBMS  server.  Transaction 
requests  are  sent  via  RT-Mach’s  Inter-Process  Com¬ 
munication  (IPC)  mechanism  and  are  queued  at  the 
server’s  service  port.  RT-Mach  provides  a  naming  ser¬ 
vice  with  which  StarBase  registers  its  service  port  dur¬ 
ing  initialization.  Clients  look  up  the  service  port 
by  querying  the  name  server  with  StarBase’s  well- 
known  name.  There  are  a  fixed  number  of  threads 
(light-weight  processes),  called  Transaction  Managers 
(TrMgr’s),  which  dequeue  those  requests  and  perform 
the  basic  operations  which  constitute  the  transaction. 
The  Transaction  Processing  unit  in  turn  implements 
these  basic  operations.  The  transaction  managers 
rely  on  lower-level  services  to  obtain  the  resources 
(memory,  relations,  etc.)  necessary  for  the  transac¬ 
tion.  These  services  are  provided  by  the  Concurrency 
Controller  (CCMgr),  the  Relation  I/O  Manager  (RI- 
OMgr),  and  the  Small  Memory  Manager  (MemMgr). 
Each  resource  manager  must  ensure  that  transactions 
access  their  resources  in  a  consistent  and  orderly  fash¬ 
ion.  Transaction  deadlines  are  enforced  by  special 
Deadline  Manager  (DMgr)  threads. 
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Figure  1:  StarBase  Server  Architecture 

2  Problems  Unique  to  RT-DBMS 

There  are  essentially  three  problems  that  real-time 
DBMSs  must  solve:  resolving  resource  contention,  re¬ 
solving  data  contention,  and  enforcing  timing  con¬ 
straints.  As  with  other  real-time  systems,  tasks  to  be 
performed  are  stratified  according  to  their  relative  im¬ 
portance  to  the  system.  Priority  combines  this  relative 
importance  with  task  timing  constraints  to  provide  a 
picture  of  which  of  the  many  tasks  should  be  scheduled 
at  any  given  moment.  The  intent  is  to  always  grant 
the  highest  priority  tasks  access  to  resources  (CPU, 
critical  sections,  etc.).  Similarly,  StarBase  considers 
each  transaction  a  task  in  its  own  right  and  seeks  to 
provide  the  best  service  to  the  highest  priority  trans¬ 
actions. 


3  Approaches  to  Resource  Contention 

Traditional  database  systems  have  sought  to  in¬ 
crease  efficiency  by  sharing  resources,  but  conven¬ 
tional  methods  for  resolving  which  thread  of  execu¬ 
tion  gets  which  resource  at  any  given  time  gener¬ 
ally  emphasize  fairness,  minimal  response  time,  or 
maximal  throughput  time.  As  previously  mentioned, 
the  goal  of  real-time  systems  is  often  to  minimize 
the  number  of  high-priority  transactions  which  miss 


their  deadlines.  Researchers  have  developed  two  tech¬ 
niques  to  resolve  resource  contention  in  a  real-time  set¬ 
ting.  First,  priority-cognizant  CPU  scheduling  algo¬ 
rithms  [6]  such  as  Rate  Monotonic,  Earliest  Deadline 
First,  and  Fixed  Priority,  afford  the  most  CPU  time 
to  tasks  with  the  highest  priorities.  Second,  for  non- 
preemptible  resources,  a  protocol  called  Basic  Priority 
Inheritance  [9]  is  used  to  ensure  the  highest  priority 
tasks  access  busy  resources  within  a  bounded  period 
of  time. 

StarBase,  like  other  applications,  is  highly  de¬ 
pended  on  its  native  operating  system,  RT-Mach  [10], 
to  help  it  resolve  resource  contention.  RT-Mach  pro¬ 
vides  several  priority-based  scheduling  regimes,  in¬ 
cluding  Fixed  Priority,  Earliest  Deadline  First,  Rate 
Monotonic,  and  Deadline  Monotonic.  RT-Mach ’s  real¬ 
time  thread  model  [10]  distinguishes  real-time  threads 
of  execution  from  ordinary  ones,  requiring  the  explicit 
specification  of  timing  constraints  and  criticality  on  a 
per-thread  basis.  The  timing  and  priority  information 
is  then  used  as  input  to  the  RT-Mach  scheduler. 

StarBase  uses  RT-Mach ’s  real-time  message  passing 
(RT-IPC)  to  ensure  that  transactions  enter  service  in 
priority  order.  Once  a  Transaction  Manager  accepts  a 
transaction  request,  RT-IPC  ensures  the  Transaction 
Manager  executes  at  the  transaction’s  priority.  RT- 
Mach  then  determines  the  rate  at  which  the  Trans¬ 
action  Manger  (and  hence  the  transaction)  progresses 
according  to  its  priority-based  CPU  scheduling.  Fi¬ 
nally,  resource  managers  such  as  the  Concurrency 
Controller  and  Small  Memory  Manager  are  guarded 
by  real-time  synchronization  mechanisms  (RT-Sync) 
to  ensure  the  highest  priority  Transaction  Mangers 
have  the  best  access  to  resources. 

For  purposes  of  uniformity,  StarBase  adopts  the 
same  data  type  that  RT-Mach  uses  to  convey  pri¬ 
orities,  facilitating  the  straightforward  translation  of 
StarBase  to  RT-Mach  priorities.  Since  the  prior¬ 
ity  data  type,  rt_priority_t,  includes  a  wide  range 
of  criticality  and  timing  information,  major  changes 
in  scheduling  policy  (e.g.,  Fixed  Priority  to  Earliest 
Deadline  First)  are  reduced  to  simple  changes  in  the 
functions  which  compare  priorities  (e.g.,  changing  the 
comparison  of  criticalities  to  one  of  deadlines)  without 
any  change  in  the  client/server  interface.  StarBase  it¬ 
self  must  make  priority-based  decisions  (e.g.,  concur¬ 
rency  control),  so  its  priority-based  comparisons  in¬ 
volve  priorities  expressed  as  rt -priority _t-typed  val¬ 
ues.  Of  course,  which  policy  is  most  appropriate  dif¬ 
fers  from  application  to  application,  so  the  policy  is  to 
be  used  is  left  as  a  compile-time  constant.  Naturally, 
StarBase  must  use  a  consistent  transaction  scheduling 
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policy  across  all  of  its  priority-based  decisions. 

Since  performance  ultimately  degrades  as  the  num¬ 
ber  of  threads  of  execution  in  a  system  increase,  and 
lazy  allocation  of  resources  adds  unpredictability  to 
the  system,  StarBase  maintains  only  a  fixed  number 
of  preallocated  transaction  manager  threads.  At  the 
same  time,  since  the  StarBase  DBMS  has  no  a  priori 
knowledge  of  transaction  workload,  more  transactions 
may  be  submitted  to  the  DBMS  than  it  can  handle 
at  any  given  time.  In  order  to  throttle  the  flow  in 
such  circumstances,  StarBase  needs  a  mechanism  to 
decide  which  requests  to  admit  into  service,  and  RT- 
Mach’s  RT-IPC  facilities  do  just  that  in  a  convenient 
and  priority-cognizant  manner. 

To  submit  a  transaction  to  the  StarBase  DBMS, 
a  client  places  the  transaction  instructions  and  prior¬ 
ity  information  into  a  message  and  uses  RT-IPC  to 
send  the  message  to  the  DBMS  server.  Since  RT-IPC 
queues  incoming  messages  in  priority  order,  the  next 
available  transaction  manager  receives  the  next  high¬ 
est  priority  unreceived  message.  Requests  are  there¬ 
fore  served  in  priority  order  and  only  the  highest  pri¬ 
ority  outstanding  requests  are  in  service  at  any  given 
time.  If  a  high  priority  transaction  request  cannot  be 
serviced  immediately  because  all  transaction  manager 
threads  are  busy  serving  some  lower  priority  requests, 
RT-IPC’s  priority  inheritance  expedites  one  or  more 
of  the  transaction  managers  so  that  the  high  prior¬ 
ity  request  enters  service  at  a  time  bounded  by  the 
minimum  of  the  in-service  transaction  deadlines. 

Once  transactions  enter  service,  StarBase  needs 
to  ensure  that  high  priority  transactions  progress  as 
quickly  as  possible.  Since  transactions  require  real¬ 
time  execution,  StarBase  creates  one  real-time  thread 
for  each  transaction  manager  and  relies  on  RT-Mach’s 
real-time  CPU  scheduling  to  schedule  them.  Transac¬ 
tion  manager  priorities  are  not  specified  explicitly  by 
StarBase,  however.  Each  obtains  the  correct  priority 
assignment  automatically  upon  receipt  of  a  new  trans¬ 
action  via  RT-IPC’s  priority  handoff  mechanism  [4]. 

Transactions,  depending  on  the  nature  of  their  op¬ 
erations,  require  some  dynamic  allocation  of  memory 
during  their  execution.  StarBase  maintains  a  Small 
Memory  Manager  to  allocate  and  manage  dynamic 
memory.  Since  transaction  managers  of  different  pri¬ 
orities  may  attempt  to  use  it  simultaneously,  entry 
into  the  Small  Memory  Manager  is  guarded  by  a  real¬ 
time  mutex  variable  to  avoid  the  priority  inversion 
problem  and  to  ensure  the  heap  is  accessed  in  mutual 
exclusion.  To  provide  (relatively)  predictable  access 
to  memory  allocated  through  the  manager,  the  heap 
is  wired  so  that  it  cannot  be  paged  out  of  physical 


memory. 

Although  the  StarBase  concurrency  controller  is  re¬ 
sponsible  for  resolving  contention  at  a  higher  level 
(i.e.,  data  contention),  it  still  relies  on  RT-Mach  to 
provide  basic  synchronization  and  avoid  the  priority 
inversion  problem.  In  particular,  the  concurrency  con¬ 
troller  must  keep  its  own  data  structures  consistent 
and  ensure  that  transaction  commits  occur  without 
interference.  As  such  the  concurrency  controller  is  or¬ 
ganized  as  a  monitor,  with  a  single  real-time  mutex 
variable  for  the  monitor  lock,  and  one  real-time  con¬ 
dition  variable  for  each  transaction  manager. 

4  Approaches  to  Data  Contention 

In  addition  to  resource  contention,  StarBase  faces  a 
problem  unique  to  DBMSs:  data  contention.  DBMS 
interpose  themselves  between  applications  and  the  raw 
unstructured  storage  media  to  provide  the  illusion  of 
atomic  operations  called  transactions.  In  order  to  pro¬ 
vide  this  illusion,  DBMS  use  concurrency  control  algo¬ 
rithms  to  give  the  appearance  that  the  data  contained 
in  relations  is  a  result  of  a  serial  execution  of  these 
transactions.  There  are  two  major  types  of  concur¬ 
rency  control  which  have  been  considered  for  use  in 
real-time  databases:  lock-based  and  optimistic  meth¬ 
ods.  In  general,  lock-based  methods  delay  transac¬ 
tions  to  avoid  having  them  access  data  in  an  inconsis¬ 
tent  way,  whereas  optimistic  methods  abort  transac¬ 
tions. 

StarBase  uses  a  real-time  optimistic  concurrency 
control  method  called  WAIT-X  [2],  which  has  been 
experimentally  shown  to  outperform  lock-based  con¬ 
currency  control  methods  in  a  firm  real-time  set¬ 
ting.  With  WAIT-X  a  transaction,  T,  executes  un¬ 
hindered  until  it  reaches  the  point  where  it  can  com¬ 
mit  (i.e.,  make  permanent  their  changes  to  the  data) 
and  WAIT-X  determines  which  transactions  T’s  exe¬ 
cution  conflict  with.  Unlike  conventional  concurrency 
control,  WAIT-X  employs  a  priority-cognizant  commit 
test:  If  high-priority  transactions  comprise  less  than 
X%  of  all  of  T’s  conflictors,  T  can  commit,  aborting 
all  conflictors  in  the  process.  Otherwise  T  waits  so 
that  higher  priority  transactions  may  proceed. 

It  was  found  experimentally  that  low  values  of  X 
tend  to  minimize  the  deadline  miss  ratio  for  light 
loads,  and  high  values  of  X  tend  to  minimize  the  dead¬ 
line  miss  ratio  for  heavy  loads.  When  X  =  50%  is  used 
as  the  threshold  value,  it  minimizes  the  overall  dead¬ 
line  miss  ratio,  but  applications  which  require  min¬ 
imization  of  the  highest-priority  deadline  miss  ratio 
must  use  a  greater  value  for  X. 
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As  an  extension  to  WAIT-X,  Star  Base  uses  a  spe¬ 
cial  conflict-detection  scheme  called  Precise  Serializa¬ 
tion  [5].  Precise  Serialization  is  an  improvement  over 
WAIT-X’s  usual  conflict  detection  and  is  aimed  at 
reducing  the  number  of  irreconcilable  conflicts  (and 
hence  the  number  of  transactions  which  must  abort). 
A  validating  transaction  which  conflicts  in  a  certain 
way  (i.e.,  has  write-read  conflicts)  is  allowed  to  com¬ 
mit,  but  its  conflictors  must  behave  as  if  they  cannot 
see  the  results  of  the  validator. 

Consider  a  case  where  a  validator,  Ty,  attempts  to 
commit  and  write  a  data  item  x  which  another  un¬ 
committed  transaction  Tcr  has  read  but  not  written. 
A  strict  prospective  validation  checks  the  writeset  of 
the  validator  against  the  readset  of  its  potential  con¬ 
flictors,  identifying  write-read  conflicts.  If  it  detects 
such  a  conflict,  the  resolution  requires  aborting  some 
of  the  conflicting  transactions.  Note,  however,  that 
if  Tcr  were  to  commit  first,  there  would  be  no  con¬ 
flict  on  data  item  x.  In  Precise  Serialization,  it  allows 
Tv  to  commit  while  Tcr  is  still  running,  but  requires 
Tcr  to  behave  as  if  it  had  committed  before  Ty .  Tcr 
is  constrained  so  that  it  cannot  read  any  data  item 
written  by  Ty  because  it  would  see  a  “future”  value, 
and  it  cannot  write  any  data  item  read  by  Ty  since 
Ty  has  committed  and  cannot  change  the  past.  Fi¬ 
nally  Ten  must  discard  (as  late  writes)  updates  to  any 
data  items  which  Ty  wrote  during  its  commit.  This 
pseudo-reserialization  of  Ty  and  Tcr  is  called  back¬ 
ward  ordering  and  its  goal  is  to  increase  the  proba¬ 
bility  that  potential  conflictors  can  complete  without 
either  aborting  and  restarting. 

Since  Precise  Serialization  is  a  conflict-detection 
scheme,  not  a  full-blown  method  of  concurrency  con¬ 
trol,  it  supplements  StarBase’s  WAIT-X  implementa¬ 
tion  rather  than  replacing  it  entirely.  Precise  Serial¬ 
ization  modifies  the  WAIT-X  validation  conflict  de¬ 
tection  and  requires  the  addition  of  a  mechanism  to 
detect  when  a  pseudo-reserialized  transaction  does  not 
behave  in  accordance  with  its  virtual  order  in  the  ex¬ 
ecution  history. 

During  validation,  Precise  Serialization  partitions 
the  set  of  conflicting  transactions  into  those  which  con¬ 
flict  reconcilably  and  those  which  conflict  irreconcil¬ 
ably.  Should  the  validator  be  allowed  to  commit,  the 
reconcilable  conflictors  must  be  pseudo-reserialized  by 
backward  ordering,  while  the  irreconcilable  conflictors 
must  be  aborted.  To  keep  track  of  which  are  which, 
StarBase  maintains  a  reserialization  candidate  set  for 
the  validator  in  addition  to  the  conflict  set  of  the 
WAIT-X  implementation  described  previously.  The 
conflict  set  still  identifies  which  transactions  conflict 


irreconcilably  with  the  validator,  but  the  candidate  set 
identifies  precisely  those  datasets  among  which  recon¬ 
cilable  write-read  conflicts  exist. 

To  construct  the  candidate  set  and  the  conflict  set 
at  the  point  of  validation,  the  CCMgr  cycles  through 
each  dataset  referenced  by  the  validator,  Ty.  If  Ty 
has  only  a  write-read  conflict  with  an  uncommitted 
transaction,  Tcr,  on  a  dataset,  then  the  serialization 
order  should  be  Tcr  — ►  Ty  (backward  validation) 
and  the  conflicting  datasets  are  added  to  the  reseri¬ 
alization  candidate  set.  If  Tcr  has  only  a  write- read 
conflict  with  Ty,  then  the  serialization  order  should 
be  Ty  — >  Tcr  (forward  validation).  In  this  case  Ty 
and  Tcr  are  considered  to  be  non-conflicting.  If  the 
CCMgr  determines  that  the  serialization  order  should 
be  simultaneously  Tcr  — ►  Ty  and  Ty  — ►  Tcr,  then 
Ty  and  Tcr  are  irreconcilably  conflicting,  and  Tcr 
is  added  to  the  conflict  set.  Note  that  the  CCMgr 
does  not  consider  write-write  conflicts  since  transac¬ 
tions  are  required  to  read  tuple  locations  to  determine 
their  values  or  to  establish  that  they  are  empty  be¬ 
fore  writing  them.  Consequently  a  writeset  is  always 
a  subset  of  the  readset  (for  a  given  transaction  and 
relation)  and  checking  both  against  a  potential  con¬ 
flictor ’s  writeset  is  redundant. 

Once  the  candidate  set  and  conflict  set  are  com¬ 
pletely  identified,  the  CCMgr  determines  whether 
the  validator  should  commit  or  wait  according  to 
the  WAIT-X  commit  test.  If  the  validator  waits, 
the  conflict  and  candidate  sets  are  discarded — they 
will  be  recomputed  if  and  when  the  validator  retries 
validation.  If  the  validator  commits,  the  transac¬ 
tions  in  the  conflict  set  are  aborted  and  the  CCMgr 
must  pseudo-reserialize  the  reconcilable  conflictors. 
Pseudo-reserialization  is  achieved  by  attaching  copies 
(or  remnants )  of  Ty ’s  datasets  to  those  datasets  with 
which  they  conflict-note  that  these  dataset  pairs  are 
precisely  those  comprising  the  reserialization  candi¬ 
date  set.  Thus  when  a  conflictor  later  updates  its  read- 
and  writesets,  it  can  quickly  check  whether  the  opera¬ 
tion  violates  its  virtual  order  in  the  execution  history 
by  consulting  the  dataset  remnants  attached  to  the 
dataset  involved  in  the  operation. 

Since  one  of  Ty ’s  datasets  may  conflict  with  more 
than  one  of  the  conflictors’,  a  remnant  is  given  a  refer¬ 
ence  count  rather  than  physically  copied.  As  conflic¬ 
tors  commit  or  abort  one  by  one,  the  CCMgr  decre¬ 
ments  the  reference  count.  When  the  last  conflictor 
terminates,  the  CCMgr  discards  Ty’s  dataset  rem¬ 
nant. 
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5  Deadline  Enforcement 

Each  StarBase  transaction  is  accompanied  by  a 
deadline  specification.  StarBase  enforces  deadlines 
on  each  transaction  with  the  aid  of  RT-Mach  facil¬ 
ities.  Applications  submit  transactions  to  StarBase 
with  application-determined  criticality  and  deadline 
information.  Since  StarBase  is  a  firm-deadline  sys¬ 
tem,  it  attempts  to  process  the  transaction  and  reply 
to  the  application  at  or  before  the  deadline;  no  pro¬ 
cessing  occurs  after  the  deadline. 

Firm  deadline  transactions  may  be  contrasted  with 
soft  deadline  transactions  which  are  viewed  as  having 
some  usefulness  even  if  their  execution  extends  beyond 
the  deadline  point.  Hard  deadline  transactions  are 
those  transactions  whose  failure  to  execute  on  time  is 
viewed  as  catastrophic. 

RT-Mach  provides  the  concept  of  a  real-time  dead¬ 
line  handler,  a  separate  thread  of  execution  which 
performs  application-specific  actions  when  the  dead¬ 
line  expires.  Typical  actions  are  to  abort  the  thread 
(firm  deadline)  or  lower  its  priority  (soft  deadline).  In 
addition  to  RT-Mach’s  real-time  threads,  implemen¬ 
tation  of  a  deadline  handler  requires  time-based  syn¬ 
chronization.  In  order  to  ensure  the  handler  action 
is  ready  to  execute  before  the  deadline,  the  real-time 
deadline  handler  must  be  eagerly  allocated  as  a  real¬ 
time  thread  to  execute  the  deadline  handler  code.  The 
deadline  handler  thread  then  uses  a  real-time  timer  to 
block  the  thread  until  the  deadline  expires.  A  real¬ 
time  timer  is  an  RT-Mach  abstraction  which  allows 
real-time  threads  to  synchronize  with  particular  points 
in  time  as  measured  by  real-time  clock  hardware  de¬ 
vices  [8]. 

RT-Mach  provides  a  default  deadline  handler  con¬ 
structed  from  the  building  blocks  discussed  above,  but 
it  is  inadequate  for  StarBase’s  purposes.  First,  the  de¬ 
fault  deadline  handler  supports  only  threads  with  uni¬ 
form  deadlines.  StarBase,  since  it  assumes  no  a  priori 
information  about  its  transaction  workload,  requires 
that  its  deadline  handlers  adapt  to  new  transactions 
and  their  deadlines  as  they  enter  service.  Secondly,  a 
RT-Mach  default  deadline  handler  forcibly  suspends  a 
thread  when  it  misses  its  deadline  so  that  the  thread 
does  not  interfere  with  the  handler’s  execution.  If  a 
thread  misses  its  deadline  while  in  the  middle  of  a  crit¬ 
ical  section,  it  is  suspended  and  cannot  leave  the  criti¬ 
cal  section  until  it  is  resumed.  StarBase  uses  a  critical 
section  to  resolve  potential  race  conditions  between 
transaction  commit  (by  the  transaction  manager)  and 
deadline  abort  (by  the  deadline  manager),  so  use  of 
a  RT-Mach-style  deadline  handler  can  result  in  dead¬ 
lock.  Thirdly,  default  deadline  handlers  do  not  allow 


the  transaction  and  deadline  managers  to  synchronize 
cooperatively.  A  deadline  manager  must  know  when 
a  transaction  completes  so  that  it  does  not  generate  a 
useless  abort;  a  transaction  manager  must  know  when 
the  deadline  expires,  so  that  it  does  not  commit  the 
aborted  transaction.  Neither  is  possible  without  some 
shared  state  which  must  be  accessed  in  mutual  exclu¬ 
sion. 

The  solution  is  to  devise  a  deadline  handler  im¬ 
plementation  which  handles  variable  deadlines,  avoids 
potential  deadlocks,  and  is  eagerly  allocated  to  pro¬ 
vide  some  degree  of  predictability  but  at  the  same 
time  takes  precedence  over  the  transaction  it  manages 
when  the  transaction  deadline  expires. 

StarBase  uses  RT-Mach’s  real-time  clock  and  timer 
facilities,  along  with  the  real-time  thread  model  to  pro¬ 
vide  a  special  deadline  handler  which  will  attempt  to 
abort  the  transaction  just  before  the  deadline  and  re¬ 
ply  to  the  client. 

First,  a  Deadline  Manager  must  synchronize  with 
the  Transaction  Manager  with  which  it  is  paired  and 
obtain  the  deadline  of  each  transaction  before  it  en¬ 
ters  service.  Next,  the  Deadline  Manager  must  wait 
either  for  the  transaction  to  complete  or  for  the  dead¬ 
line  to  expire.  If  the  deadline  expires,  the  Deadline 
Manager  must  abort  the  transaction  asynchronously 
with  respect  to  the  Transaction  Manager  processing 
it.  StarBase  has  a  scheme  to  ensure  that  the  Deadline 
Manager  is  scheduled  in  preference  to  its  Transaction 
Manager  by  assigning  it  a  slightly  higher  criticality 
and  slightly  tighter  timing  constraints  than  the  Trans¬ 
action  Manger. 


6  Conclusions  and  Future  Work 

In  this  paper,  we  have  presented  the  architecture 
to  support  a  firm  real-time  DBMS  assuming  no  a  pri¬ 
ori  knowledge  of  transaction  workload  characteristics. 
Unlike  previous  simulation  studies,  StarBase  uses  a 
real-time  operating  system  to  provide  basic  real-time 
functionality  and  deals  with  issues  beyond  transaction 
scheduling:  resource  contention,  data  contention,  and 
enforcing  deadlines.  Issues  of  resource  contention  are 
dealt  with  by  employing  priority-based  CPU  and  re¬ 
source  scheduling  provided  by  the  underlying  real-time 
operating  system.  Issues  of  data  contention  are  dealt 
with  by  use  of  a  priority-cognizant  concurrency  con¬ 
trol  algorithm  with  a  special  conflict-detection  scheme, 
called  Precise  Serialization,  to  reduce  the  number  of 
aborts.  Issues  of  deadline-handling  are  dealt  with  by 
constructing  deadline  handlers  which  synchronize  with 


321 


the  start  and  end  of  a  transaction  and  which  don’t  in¬ 
terfere  with  its  execution  until  the  deadline  expires. 

The  correctness  of  the  concurrent  execution  of 
transactions  on  StarBase  has  been  demonstrated  by  a 
special  demonstration  program.  The  program  graphi¬ 
cally  depicts  a  high-priority  writer  obtains  better  per¬ 
formance  than  a  concurrently-executing  low-priority 
writing  transaction.  There  is  still  plenty  to  accom¬ 
plish,  however.  Future  work  includes  the  extension 
of  the  query  language  to  include  set-based  relational 
algebra  operations,  the  reduction  of  data  conflicts  by 
the  use  of  a  specially-designed  indexing  mechanism. 
Another  interesting  future  work  is  to  extend  these  so¬ 
lutions  to  the  situation  in  which  transaction  character¬ 
istics  are  at  least  partially  specified  beforehand.  With 
prior  knowledge,  a  real-time  DBMS  can  preallocate 
resources  and  arrange  transaction  schedules  to  mini¬ 
mize  conflicts,  resulting  in  more  predictable  service. 
Execution  time  estimates  and  off-line  analysis  can  be 
used  to  increase  DBMS-wide  predictability.  We  also 
plan  to  port  StarBase  to  other  real-time  operating  sys¬ 
tems  and  identify  operating  system  services  essential 
to  supporting  StarBase.  Once  the  basic,  real-time, 
POSIX.4-compliant  functionality  needed  to  support  a 
firm  real-time  database  has  been  established,  StarBase 
can  be  ported  to  other  platforms. 
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